In the work done of path segment protecting p-cycles, such as G. Shen, W. D. Grover, “Extending the p-cycle concept to path segment protection for span and node failure recovery,” IEEE Journal on Selected Areas in Communications, vol. 21, no. 8, October 2003, pp. 1306-1319, it was explained that (paraphrasing):                “ . . . It was natural, even at the time of the first work on span-protecting p-cycles, to ask if there was a path protection equivalent to basic span-protecting p-cycles. As simple as basic p-cycles are the latter question turned out to be difficult to address. Ultimately the difficulty is how to handle the aspect of “mutual capacity” contention which is intrinsic to any path oriented or multi-commodity flow type of recovery scheme in formulating the design model under a paradigm of cyclic spare capacity structures. The corresponding operational complexity in trying to coordinate which paths can access which p-cycles, for which failures, were also beyond reach at the time.”        
In the work on flow p-cycles, these difficulties were partly overcome by allowing the insistence specifically of end-to-end path protection to be relaxed to become protection for arbitrarily defined path segments. Accordingly the concept improves on the spare capacity efficiency of regular p-cycles but it was recognized that the operational aspects were quite complicated, failure specificity remained, and the simplicity of strict end to end switchover to a predefined backup path was not achieved.
The concept of flow p-cycles is described with the aid of FIGS. 3A and 3B. FIG. 3A is an example of a span protecting p-cycle and FIG. 3B is the same cycle viewed as a flow-protecting p-cycle. In FIG. 3A the spans (0, 2), (2, 3), (3, 5), (5, 6), (6, 8), and (8, 0) are on-cycle spans of the regular p-cycle shown. The span (0, 5) is not on the cycle, but its two end nodes are, making it a straddling span. Note, however, that spans (6-7) and (7-2), and several others are “close to” being straddling spans but cannot actually be span-protected by the cycle shown. However, an individual service path that crosses both spans (6-7) and (7-2) as in FIG. 3B can be considered to straddle the cycle shown when taking a path-level view of only the one demand that flows all the way across the p-cycle. More specifically the path segment (6-7-2) can be considered to straddle the cycle shown, between the nodes 6 and 7 as long as the total working flow remains contiguous over this segment. These basic observations lead to the concept of flow- (or segment-) protecting p-cycles. Flow p-cycle designs can access more opportunities for spare-capacity-sharing than the span p-cycle method and have an additional advantage of node failure recovery. Any flow segment that intersects a flow p-cycle can be protected, not simply spans directly on, or straddling the cycle. For example, if spans (2, 7) and (6, 7) in FIG. 3A incur failures, they cannot be restored by a span-protecting p-cycle. But, under the flow p-cycle shown in FIG. 3B, the contiguous flows that traverse spans (2, 7) and (6, 7) can be restored by the cycle. Also, flow p-cycles can recover transit traffic demands due to the loss of an intermediate node on a flow. A failure of intermediate node 7 can break the flows between node pairs (1, 10) and (4, 9). The span-protecting p-cycle in FIG. 3A cannot restore these affected transit flows; however, under the flow p-cycle shown in FIG. 3B, the flows that transit node 7 can be recovered by the cycle. Note, however that any demands being added or dropped at node 7 cannot be handled by the same flow p-cycle. The flow must be unchanged in its composition between the nodes where it intersects the flow p-cycle.
Given a cycle that is a candidate to be a flow p-cycle in a network design, the relation of any given path to the cycle can be either intersecting or non-intersecting. Only intersecting paths are relevant to the consideration of each candidate cycle. A path intersects a cycle if the two have at least two common nodes (which may include the source and destination nodes of the path). These are called intersection nodes. For example, the paths between nodes (4, 9) and (1, 10) in FIG. 3B both intersect the cycle shown and are relevant to the consideration of that cycle as a possible flow p-cycle. By inspection, that cycle would provide straddling-type protection to the two segments (6-7-2) and (0-7-6) and on-cycle protection to an example flow such as (6-5-3) should it exist. More generally, a path can intersect a cycle in a variety of more complex ways, involving more than two intersecting nodes.
The various types of intersections between flow segments and prospective p-cycles have to be determined for flow p-cycle design. FIG. 4A displays the simplest scenario, where the cycle and the relevant flow segment intersect at two nodes and the flow does not share any other spans or nodes with the cycle. FIGS. 4B through 4E show other and more general intersecting flow relationships, which can be arbitrarily complex, such as in FIG. 4E. Thus, in flow p-cycles a pre-processing program is used to identify all the protection relationships between candidate cycles and the corresponding flow segments. These are fed into the design model.
Operational Aspects of Flow P-Cycles
The main new considerations in flow p-cycles (that are not needed with span p-cycles) are the need to locate and transmit information in real time and the need for a mechanism by which the flow p-cycles are employed in a failure-specific way also in real time. In flow p-cycles it is assumed that at the time a p-cycle j is established through a node x, a list of the corresponding protected flow segments that intersect the cycle at that node is recorded in association with the p-cycle. The Signal_ID of the working path of which the p-cycle protects a segment is also recorded at the node for each span failure on the flow segment. In effect this data sets up matching conditions for node x to know locally which working signals (if any) it should switch into p-cycle j, depending on which span fails on any of the flow segments passing through it. Upon failure, node x is either adjacent to the failure, in which case it sees LoS, or AIS is inserted downstream by the two nodes adjacent to the failure. All working signals bear a unique signal_ID in their overheads and, any time a node inserts AIS, it appends the ID of the incident span that has failed. Thus, the failure indication data {AIS, Signal_ID=Z, span_ID=k} passes through all nodes on the failed path. But only node x will have been “pre-wired” with the matching conditions to associate Signal_ID=Z with locally accessible p-cycle j if an indication of its failure arrives, arising from span k. Thus a logical matching rule can be applied at any node seeing an AIS indication to quickly determine if it has a custodial responsibility to do protection switching for the failed signal. FIG. 5 summarizes the principal concept. The concept requires failure detection and AIS insertion at each node. Also described in G. Shen, W. D. Grover, “Extending the p-cycle concept to path segment protection for span and node failure recovery,” IEEE Journal on Selected Areas in Communications, vol. 21, no. 8, October 2003, pp. 1306-1319 is how the scheme may be more amenable to centralized control. A centralized control and management system maintains a database of network state and computes a suitable flow p-cycle configuration. The cross-connect commands and pre-planning information to create the desired p-cycles and to trigger failure specific p-cycle use is all downloaded based on the current set of demands being served and their protection classes. The centralized approach may suffer from the limitation of a heavy computing load and a high failure risk of the central network control manager. Thus, “flow p-cycles” are a significant extension to the basic method of p-cycles. The key idea is to define and employ p-cycles that protect segments of continuous demand flow. This frees the design from the strict requirement of protecting only spans that either form part of the cycle or lie on the cycle or directly straddle the p-cycle. But the technique protects arbitrary segments of paths determined during the capacity design phase, not end-to-end paths and it requires failure detection at each span for correct activation of the flow-protecting p-cycles in a failure-specific way. Fairly complex pre-planning information must be established and maintained at each node for each flow p-cycle going through it, so that each p-cycle knows which failed path segments it has custodial responsibility for depending on each possible span failure.
Shared Backup Path Protection (SBPP)
In a path-restorable network or a path-protected network, the reaction to a failure takes place from an end-to-end viewpoint for each service path affected by the failure. The end-to-end viewpoint means that the replacement path is determined as a completely new routing from the origin to destination node of the path. Path-oriented survivability schemes have several advantages over span-oriented techniques. SBPP is a special case of path restoration in general, where one backup path is predefined for each working path and no matter what fails on the working path, restoration is via a path assembled on demand over this one predetermined backup route. The backup route is fully disjoint from the route of the working path. In this scheme it is possible for the users to know ahead of time exactly where their service will be rerouted in a failure. This is sometimes said to be important to customers. Also, because path restoration (or protection) spreads the overall rerouting problem more widely over a network, SBPP can also usually be more capacity-efficient than span restoration designs. Node failure survivability is not as gracefully derived from span restoration techniques, but has to be obtained somewhat separately from the additional design of a set of NEPCs. Path-oriented schemes provide an inherent form of response against node failure. Another property of the SBPP scheme that can be especially useful in transparent optical networks is that fault isolation and detection is not necessary in real time to determine the restoration response. The response is the same no matter where on the working path a failure occurs. This property is called “failure independence” and it is of advantage in transparent or translucent optical networks where real-time signal monitoring may not be possible at intermediate nodes. In such networks therefore, fault isolation and detection is slow, difficult, or impossible until off-line Optical Time Domain Reflectometry (OTDR) measurements are made or such. But only the end-nodes of the path affected by a failure need to detect the failure, to activate the appropriate response and that is always just a single end-to-end switchover to the backup route. It also does not matter whether it is a node or span that failed because in both cases the end-nodes of the failed working path will simply see a loss of signal or loss of light on the specified line-cards.
On the other hand, path restoration or protection schemes are generally not as fast as their span-oriented counterpart due to the greater distances and numbers of nodes involved in signalling. SBPP in particular has to form the backup path along the preset route, after the failure, in real time. There are therefore obvious issues of scalability due to backup-sharing databases with SBPP and generally greater overall complexity is inherent with path restoration: SBPP and dynamic path restoration both involve considerations to address the “mutual capacity” issue which is the central complicating difference between span and path restoration.
It is important to note that although SBPP is a failure-independent path-oriented scheme where the protection route is completely identified in advance, spare capacity has to be cross-connected on the backup route in real-time. In this regard SBPP is somewhat mis-named: it is really best described as a pre-planned restoration scheme. In contrast FIPP p-cycles provide a true protection scheme where backup paths are completely predefined and fully pre-cross-connected prior to failure.
As so far described SBPP is like 1+1 APS where two fully disjoint paths, a working and a backup are established for each signal. For efficiency in the use of spare capacity, however, SBPP includes sharing of spare channels over the backup paths for different working path failures. The key ideas for routing under SBPP are that one tries to route the working path over the shortest or least cost path over the graph while also considering the disjoint backup routes this allows and their potential for sharing of spare capacity. Often under SBPP the working paths are called “primary” paths. Usually, but not always, there will be one or more possible backup routes between the same end nodes of the primary path. To be eligible as a backup route, a route has to have no nodes or spans in common with the route of the primary path and no spans or nodes in common with any other primary path whose backup route has any spans in common with the route being considered. Together these considerations ensure that when a primary path fails (under any single failure scenario):                a) No span or node along its backup route is simultaneously affected. This means it will be possible to assemble a backup path along that route if sufficient spare channels have been pre-planned. This can be called the self-disjointness requirement of the backup route, and is the fairly obvious condition for survivability.        b) No other primary path that is affected by the same failure has a pre-planned backup path that assumes the use of the same spare channel(s) on any span of the first primaries backup route.        
This is referred to as the failure disjointness requirement and is not actually needed to enable survivability, but is required to enable the efficient sharing of spare channels over different backup routes. This more complicated set of considerations basically makes sure that if primary A and B are both pre-planned to use a certain spare channel on span X in their backup routes, then there is no (single) failure where primaries A and B would ever both need that spare channel at the same time. (If they did, then two spare channels must be provided on span X to be used simultaneously, instead of one spare channel only, which can be shared by A and B over failures that do not happen simultaneously.)
As a last consideration, the preferred choice for the backup route (assuming there are several possibilities) is the one that requires the fewest new channels of spare capacity to be placed (or committed from the available capacity). In other words one tries to chose a backup route on which a backup path can be formed for primary A which, to the greatest extent possible, assumes the use only of spare channels already associated with other primaries that have no “shared risk” in common with primary A. Backup paths may share a spare channel because their corresponding primary paths have no common-cause failure scenarios (and so would not ever have a simultaneous need to use the shared backup channel). Technically, such primary paths are said to have no Shared Risk Link Groups (SRLG) in common. As a result, one unit of spare capacity is saved on the common span relative to dedicated 1+1 APS for the same two primary paths. Depending on network details, it has been found that if at most three to five such sharing relationships or “claims” are allowed to be established by diverse primaries on each spare channel, the minimum total investment in spare capacity can be approached.
FIG. 6A through 6D illustrates the concept of spare capacity sharing on predefined backup routes in a network context. FIG. 6A shows the network 600 used in the illustration. Four mutually disjoint working routes 602, 604, 606 and 608 are shown between node pairs A-C, E-G, L-G and L-H, respectively, in FIG. 6B. FIG. 6C shows possible routes 610, 612, 614, and 616 of the protection paths for the four primaries in FIG. 6B. For example, demand A-C follows the working route 602 along A-B-C for which the corresponding protection route is 610 along A-D-O-G-C. Since these working routes are all mutually disjoint, spare capacity can be shared on their backup routes. For example 610 along A-D-O-G-C and 612 along L-E-D-O-G share the D-O-G segment and therefore as shown in FIG. 6D require only one channel of spare capacity on D-O-G per working channel on routes 602 along A-B-C and 604 along E-P-G. The grey shaded areas in FIG. 6D indicate the three spans, DO, OG, NO where sharing is possible. Of these OG achieves maximal sharing with four separate working routes sharing a single unit of spare capacity (per unit working capacity) along the backup route. Note in FIGS. 6B to 6D that it is individual spare channels that this mechanism is organized to share and it is not possible to have these channels cross-connected in advance of failure because it is not known which of the specific backup paths in FIG. 6C might be needed until failure actually occurs. Ultimately, it is because SBPP sharing is structured on a per channel basis, over groups of mutually disjoint primaries, that SBPP requires cross-connection in real time to form actual restoration paths. Each primary plus backup path pair, viewed in isolation, thus forms a 1+1 APS-like arrangement.